home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Chip 2000 September
/
Chip_2000-09_cd1.bin
/
sharewar
/
Slunec
/
app
/
16
/
COMM.SWG
/
0013_QWKE (Extended?) v1.0.pas
< prev
next >
Wrap
Pascal/Delphi Source File
|
1997-05-11
|
16KB
|
425 lines
QWKE Specifications 1.0
(also known as EQWK - pronounced Quicky, and E-quick respectively)
Copyright 1994, Peter Rocca
Fidonet 1:2401/123
(519) 660-8981 / (519) 660-6908
28,800 Baud
This documentation may be freely used to enhance/create 1st, 2nd or 3rd
party applications or utilities without any legal obligation to the author.
Please do not extend or further the QWKE without contacting Pete Rocca, in
order to keep the standard from becoming a 'non-standard'. - Thank you.
QWKE Specifications
───────────────────
All files and formats match the QWK 1.0 standards. If you are not familiar
with them, I would suggest getting QWKLAY??.ZIP by Patrick Y. Lee. (it is
freqable from my system)
The only differences to the standard QWK format lay in four files.
CONTROL.DAT - conference area names are no longer limited
to 13 characters, they are limited to 255
characters now.
DOOR.ID - contains additional CONTROLTYPE names.
TOREADER.EXT - a file created by the door that contains
additional information for the reader.
TODOOR.EXT - a file created by the reader that contains
additional information for the door.
In addition, certain kludge lines should be imported to messages when
downloading, if their length exceeds 25 characters.
These kludges are...
To:
From:
Subject:
...they should be at the top of the message, and terminated by
either a carriage return, or the 'π' QWK terminator. At the end
of the last imported kludge, there should be a blank line, however
you should program to handle if one is not present. Additional
kludge names can be created, but your reader/door should at least
handle these three.
Also, the kludge lines To/Subject should be imported into the message
fields when posting the messages. (uploading) The From kludge can
be accepted, but remember to check the security of it (ie make sure
that the name is allowed, ie alias base, etc) Also, regarding the
To: kludge... keep in mind that UUCP software likes the To: line
left in the first line of a message, therefore it should not be
removed from the message if this message is destined to be sent
through an UUCP gateway.
A sample message with kludge lines might look like:
1 10 20 25
|---+----|----+----|----|
TO:PETER ROCCAZISKINZIDONING
FROM:BOB WILIKERS
SUBJ:This is a test of the sys <--- HEADER
--------------------------------------------------------------------
To: PETER ROCCAZISKINZIDONINGLY <--- MESSAGE TEXT
Subject: This is a test of the system, as you can see!
<blank line>
The real message starts here now, but it was short, so
see you later.
As you can see, only the To/Subject lines were imported, since the
From line did not exceed the 25 character limit.
══════════════════════════════════════════════════════════════════════════════
File: TOREADER.EXT
──────────────────
Desc: This file is simply an ASCII text file that is included
in the QWK packet, and contains information used by the
QWK reader. (created by the mail door)
Each line has an identifier, followed by the relevant information
for the extended information. (Arguments in < > are required,
and ones in [ ] are optional)
ALIAS <users' alias name>
AREA <conference#> <settings>
BULL <filename> <description>
ATTACH <filename> <conference#> <message#>
FILE <filename> [description]
KEYWORD <keyword>
FILTER <filter>
TWIT <twit>
──────────────────────────────────────────────────────────────────────────────
Identifier: ALIAS <users' alias name>
This simply passes the users' alias name to the door in order to be
able to present it to the user when entering mail in 'alias' areas.
An example would be: ALIAS Rawhide
──────────────────────────────────────────────────────────────────────────────
Identifier: AREA <conference#> <settings>
This presents a list of selected areas (or all areas optionall), and
what the flag settings for each area are. The <conference#> is the
number of the area that is selected and the <settings> contains the
flags for that area.
The possible flags are:
a for all messages
p for personal messages
g for general messages (personal and those addressed to 'ALL')
In addition, some mail doors can add the following flags:
w if this area should include mail written by themselves
k if this area should be included in keyword searches
f if this area should be included in filter exclude searches
F if this area is forced to be read
B if this area is blocked from getting replies
In further addition, area information should be given.
P if the area is private mail only
O if the area is public mail only
X if either private or public mail is allowed
R if the area is read-only
Z if the area doesn't allow replies
L if the area is a local message area
N if the area is a netmail area
E if the area is an echomail area
I if the area is an internet area
U if the area is an newsgroup area
H if the area is an handles only message area
A if the area allows messages 'from' any name (pick-an-alias)
& if the area allows file attaches
(does not override CONTROLTYPE=ALLOWATTACH)
Again the door should enforce security to messages with private
flags and/or different names to ensure that they are allowed.
For example, if a user had 4 areas selected, it might look like this:
AREA 23 awOU
AREA 31 aFPLA
AREA 44 pkPN&
AREA 172 gwkfPI
...please note that the flags ARE case sensitive & and any unknown
flags should be ignored.
──────────────────────────────────────────────────────────────────────────────
Identifier: BULL <filename> <description>
This is a way of describing the bulletins a little better than
the file name BLT-x.y method. The actual files should still be
in the BLT-x.y format to ensure backward compatibility, but by
describing the filenames here, you can have something like
looks like:
Bulletins
- System Stats
- Top Users
- Contest galore!
Instead of:
Bulletins
- BLT-1.4
- BLT-3.2
- BLT-6.1
In this example, the TOREADER.EXT file would have three lines
added to create these descriptions:
BULL BLT-1.4 System Stats
BULL BLT-3.2 Top Users
BULL BLT-6.1 Contest galore!
──────────────────────────────────────────────────────────────────────────────
Identifier: ATTACH <filename> <conference#> <message#>
This is a method used to identify which messages have files attached
that were downloaded with the packet. It is upto the mail door
to decide whether or not to send attached files, this is simply a
method for the reader to acknowledge such files.
For an example: Say that message number 782 in conference 12 had
the file TEST.ZIP attached to it, and the mail door included this
TEST.ZIP file in the BOARDID.QWK archive. The TOREADER.EXT file
would have the follow entry to let the mail reader know about this
file.
ATTACH TEST.ZIP 782 12
──────────────────────────────────────────────────────────────────────────────
Identifier: FILE <filename> [description]
This is a method used to identify which files in the QWK archive
are file requests from the bulletin board. It is upto the mail door
to decide whether or not to send these requested files, and this
is simply a method for the reader to acknowledge such files.
For an example: Say that the file GOODGAME.ARJ was requested and
added to the BOARDID.QWK archive. When the mail reader expanded it,
it would not know which files had been requested by the user, nor
what the description of those files were. Place using the FILE
identifier, the reader can easily present a nice listing of requested
files, rather than having to guess at the file names, and having
no idea of the description (although the description is optional).
In the GOODGAME.ARJ example, the mail door should add the following
line to the TOREADER.EXT file.
FILE GOODGAME.ARJ This is a great new SVGA action game!
or
FILE GOODGAME.ARJ
──────────────────────────────────────────────────────────────────────────────
Identifier: KEYWORD <data>
Identifier: FILTER <data>
Identifier: TWIT <data>
These identifiers are for mail doors that can process keywords,
filters and twit listings. It is used only to inform the mail
reader of the settings used, in order to make offline configuration
much easier for the user. For example, if the TOREADER.EXT file
had the following lines...
KEYWORD olms
KEYWORD qwk
FILTER hacking
TWIT Death Wizard
...then the mail reader could present a list of these settings
and allow changes to be made to them, and create the proper
TODOOR.EXT lines to alter the configuration.
══════════════════════════════════════════════════════════════════════════════
File: TODOOR.EXT
────────────────
Desc: This file is simply an ASCII text file that is included
in the QWK packet, and contains information used by the
QWK mail door. (created by the mail reader) It must be
read back and processed by the door.
Each line has an identifier, followed by the relevant information
for the extended information. (Arguments in < > are required,
and ones in [ ] are optional)
AREA <conference#> <settings>
RESET <conference#> [#ofmessages]
ATTACH <filename> <reply#>
FILE <filename> [description]
REQUEST <filename>
REQUEST <conference#> <message#>
KEYWORD [-]<keyword>
FILTER [-]<filter>
TWIT [-]<twit>
──────────────────────────────────────────────────────────────────────────────
Identifier: AREA <conference#> <settings>
This presents a list of CHANGES areas, and what the flag settings
for each area changed are. The <conference#> is the number of the area
that is to be changed and the <settings> contains the flags for that area.
The possible flags are:
D drop area
a for all messages
p for personal messages
g for general messages (personal and those addressed to 'ALL')
In addition, some mail doors can add the following flags:
w if this area should include mail written by themselves
k if this area should be included in keyword searches
f if this area should be included in filter exclude searches
For example, if a user had changed 2 areas, it might look like this:
AREA 23 D
AREA 44 gf
──────────────────────────────────────────────────────────────────────────────
Identifier: RESET <conference#> [#ofmessages]
This presents a list of pointer changes to be made. The pointers should
be changed for the <conference#> given. If the [#ofmessages] is blank
then the pointer should be set back to the start of the message base,
otherwise it should be set back [#ofmessages] back from the end of
the message base.
For example, if a user had modified 2 areas, it might look like this:
RESET 23 100
RESET 44
──────────────────────────────────────────────────────────────────────────────
Identifier: ATTACH <filename> <reply#>
This is a method of creating messages that have files attached
to them. The mail reader should pack the <filename> into the
BOARDID.REP file, and add this line in the TODOOR.EXT file,
which is also included in the BOARDID.REP file.
The <reply#> is the number of the message in the reply packet.
For example, if the third message in the reply packet had the
file ATTACHME.ZIP attached to it: The BOARDID.REP file should
contain the file ATTACHME.ZIP, BOARDID.MSG and the TODOOR.EXT
file. The TODOOR.EXT file would contain the line...
ATTACH ATTACHME.ZIP 3
...within it. NOTE! that it is upto the mail door whether or not
it will allow files to be attached to messages. This is governed
by the mail door inserting the line CONTROLTYPE=ALLOWATTACH in
the DOOR.ID file.
──────────────────────────────────────────────────────────────────────────────
Identifier: FILE <filename> [description]
This is a method of uploading files in your mail packet. These
are general public files, and should be processed for credit on
the bulletin board.
For example, if you included a file called GOODGAME.ZIP in your
BOARDID.REP file for credit on the BBS, the mail reader should
insert the line...
FILE GOODGAME.ZIP This is a great new game!
... in the TODOOR.EXT file. It is upto the mail door whether
or not it accepts files to be uploaded with the mail packets.
This can be detected by the CONTROLTYPE=ALLOWFILES line
being added to the DOOR.ID file in the downloaded packet.
The <reply#> is the number of the message in the reply packet.
For example, if the third message in the reply packet had the
file ATTACHME.ZIP attached to it: The BOARDID.REP file should
contain the file ATTACHME.ZIP, BOARDID.MSG and the TODOOR.EXT
file. The TODOOR.EXT file would contain the line...
ATTACH ATTACHME.ZIP 3
...within it.
──────────────────────────────────────────────────────────────────────────────
Identifier: REQUEST <filename>
Identifier: REQUEST <conference#> <message#>
These are file requests, either for files on the board, or files that
are attached to messages.
"REQUEST bob.zip", would request the file BOB.ZIP from the BBS's file
collection, whereas "REQUEST 12 333", would request the files attached
to message #333 in conference #12. It is upto the door to provide
security as to what can be requested.
──────────────────────────────────────────────────────────────────────────────
Identifier: KEYWORD [-]<data>
Identifier: FILTER [-]<data>
Identifier: TWIT [-]<data>
These identifiers are for changes made to the keywords, filters
and twit listings. It is used only to process CHANGES therefore
if the setting "KEYWORD bob" was given, it does not mean it is
the only keyword in the list, rather added to the list of keywords.
To remove an entry, precede it with a minus sign (-), so an example
to remove a keyword "bob" from the list of keywords would be
"KEYWORD -bob"
══════════════════════════════════════════════════════════════════════════════
Additional CONTROLTYPE= settings (DOOR.ID file)
───────────────────────────────────────────────
CONTROLTYPE=MAXKEYWORDS <#> -> max keywords the door can handle
CONTROLTYPE=MAXFILTERS <#> -> max filters the door can handle
CONTROLTYPE=MAXTWITS <#> -> max twits the door can handle
CONTROLTYPE=ALLOWATTACH -> if the door allows file attachments
CONTROLTYPE=ALLOWFILES -> if the door allows files to be uploaded
CONTROLTYPE=ALLOWREQUESTS -> if the door allows files to be requested
CONTROLTYPE=MAXREQUESTS -> max number of daily file requests
══════════════════════════════════════════════════════════════════════════════
History
───────
Rev 1.00, 10/12/94 : Released official standard
- End Documentation -